In the past decade the world has seen an explosion in Internet activity and with it has come increased expectations for performance and services. Internet users now demand faster response and new services such as quality of service (QoS), voice over IP (VoIP) and the bandwidth-intensive video streaming. The Internet serves TCP (Transmission Control Protocol) flows and UDP (User Datagram Protocol) flows.
TCP is a set of rules (protocol) used along with the Internet Protocol (IP) to send data in the form of message units between computers over the Internet. While IP takes care of handling the actual delivery of the data, TCP takes care of keeping track of the individual units of data (called packets) that a message is divided into for efficient routing through the Internet.
UDP is a communications protocol that offers a limited amount of service when messages are exchanged between computers in a network that uses the Internet Protocol. UDP is an alternative to TCP and, together with IP, is sometimes referred to as UDP/IP. Like TCP, UDP uses the Internet Protocol to actually get a data unit (sometimes called a datagram) from one computer to another. Unlike TCP, however, UDP does not provide the service of dividing a message into packets (datagrams) and reassembling it at the other end. Specifically, UDP doesn't provide sequencing of the packets that the data arrives in. This means that an application program that uses UDP must be able to make sure that the entire message has arrived and is in the right order. UDP flows do not react to any signaling from the network.
TCP implements an algorithm for flow control called Sliding Window. The “window” is the maximum amount of data we can send without having to wait for acknowledgements (ACKs). In summary, the operation of the algorithm is as follows:
1. Transmit all the new segments in the window.
2. Wait for acknowledgement/s to come (several packets can be acknowledged in the same ACK).
3. Slide the window to the indicated position and set the window size to the value advertised in the acknowledgement.
When we wait for an acknowledgement to a packet for some time and it has not arrived yet, the packet is retransmitted. When the acknowledgement arrives, it causes the window to be repositioned and the transmission continues from the packet following the one transmitted last.
The Sliding Window Flow Control assures we are not going to overload the other peer, but does not take care of network congestion. That is, the bottleneck can be (and will probably be) the network, not the receiver. The network can absorb short traffic bursts over its capacity by buffering them on the nodes. If equilibrium is reached, then self-clocking works and solves the problem. However, if we persistently try to deliver to the network more packets than it can absorb, we will fall on network congestion. It is possible that packets take so long to arrive at the other side that our timeouts will expire and we will retransmit packets unnecessarily, wasting bandwidth and increasing the congestion even more. The nodes can reach their memory limit and begin dropping packets, which we will have to retransmit (wasting bandwidth and adding extra traffic to the network that becomes even more congested). Drops are worse than they seem: when we drop a packet, the receiver cannot acknowledge further ones until the lost one arrives; therefore, we run out of send window and we have to wait for a timeout to occur, retransmit the lost packet, and wait for the cumulative acknowledgement of all the packets to continue the transmission.
There is a clear need for relatively simple and coarse methods of providing differentiated classes of service for Internet traffic, to support various types of applications, and specific business requirements. The Differentiated Services (“DiffServ”) approach to providing quality of service in networks employs a small, well-defined set of building blocks from which a variety of aggregate behaviors may be built. A small bit-pattern in each packet, in the IPv4 TOS octet or the IPv6 Traffic Class octet, is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior (PHB), at each network node. A common understanding about the use and interpretation of this bit-pattern is required for inter-domain use, multi-vendor interoperability, and consistent reasoning about expected aggregate behaviors in a network. An Internet Engineering Task Force (IETF) working group has standardized a common layout for a six-bit field of both octets, called the ‘DS field’. IETF RFC 2474 and IETF RFC 2475 define the architecture, and the general use of bits within the DS field.
Diffserv provides different services in a scalable manner to users of the Internet. Diffserv adheres to a basic Internet philosophy, i.e., complexities should be relegated to a network edge while preserving simplicity of a core network. Two-hop behaviors are standards in the IETF, i.e., expedited forwarding (EF) and assured forwarding (AF). EF is intended to support low delay applications while AF is intended to provide throughput differentiation among clients according to a negotiated profile.